Conventionally, a navigation terminal detects its current location, that is, an origin of a trip through a Global Positioning System (GPS) connection, receives information about a destination of the trip from a user, and internally calculates a route based on the origin and the destination. Along with the recent proliferation and increased performance of smartphones, services have become popular, in which a traffic and route information providing server provides route information, real-time traffic information related to routes, and other various information to Personal Navigation Devices (PNDs) over a mobile communication network.
Particularly in the situation where various navigation services are available, the Open Mobile Alliance (OMA) standardization organization is working on standardization of Dynamic Navigation Enabler (DynNav) that provides real-time traffic information by Peer to Peer (P2P) communication through an Internet Protocol (IP)-based network of a mobile communication network or a wireless network, rather than Traffic Protocol Expert Group (TPEG) information is transmitted over a Digital Multimedia Broadcasting (DMB) network that provides information in a broadcast signal. The standard considers a navigation terminal and a service type largely in two ways for a smartphone.
First, a traffic and route information providing server performs complex route computation, instead of a navigation application loaded in a smartphone, and indicates a calculated route to the smartphone. Second, owing to the improved performance of a smartphone, an application loaded in the smartphone performs or a navigation terminal equipped with a mobile communication modem performs route computation. In this case, the traffic and route information providing server does not provide route information. Rather, once the terminal registers a calculated route to the server, the terminal can receive from the server only real-time traffic information related to the registered route in a customized manner by IP-based P2P communication, not in a conventional broadcast signal.
FIG. 1 illustrates Navigation Device (ND) types. NDs may be classified into a type 110 that additionally provides TPEG-based traffic information transmitted through a broadcasting network such as a DMB network, a type 120 that additionally provides traffic information in an IP-based manner, for example, over a mobile communication network or a Wireless Fidelity (Wi-Fi) network, and a standalone type 130 that tracks the location of a vehicle through a GPS connection without connecting to other communication media, generates route information, and provides the route information.
DynNav under standardization in the OMA LOC WG belongs to the type 120 that provides IP-based traffic information, specifically by P2P communication. The following two types of NDs are defined in DynNav.
1. Smart ND: a device that can calculate a route on its own and thus requests only real-time traffic information to a DynNav server without receiving route information from the DynNav server.
2. Lightweight ND: a device that cannot calculate a route on its own and thus requests all real-time traffic information including route information to a DynNav server.
Since traffic information is requested and provided in a RESTful-based manner in a conventional DynNav system, the following route information formats are used and each information format can be defined by XML Schema Definition (XSD).
1) Trip Structure: a terminal initially acquires basic information such as an origin and a destination from a user, for route setting, and provides the acquired information to a server. The trip structure includes subsets corresponding to a plurality of route structures.
TABLE 1ElementTypeOptionalDescriptionoriginWGS84Location_PointYesLocation information about an originrepresented by WGS84 (Location_Pointstructure is defined in tpeg-locML [TTI LOC].At least one element originWGS84 ororiginAddress MUST be specified.)originAddressCivic LocationYesLocation information about the originFormatrepresented as a civic location (Civic LocationFormat is defined by IETF [RFC 5139]. Atleast one element originWGS84 ororiginAddress MUST be specified.)destinationWGS84Location_PointYesLocation information about a destinationrepresented by WGS84 (Location Pointstructure is defined in tpeg-locML [TTI LOC].At least one element destinationWGS84 ordestinationAddress MUST be specified.)destinationAddressCivic AddressYesLocation information about the destinationFormatrepresented as a civic location (Civic LocationFormat is defined by IETF [RFC 5139]. Atleast one element destinationWGS84 ordestinationAddress MUST be specified.)waypointsLocation_PointYesLocation information about a way point[0 . . . unbounded](represented by WGS84)(Location_Pointstructure is defined in tpeg-locML [TTILOC].)startingTimexsd:dateTimeYesStarting time of navigation service (if a servicestarting time is specified, the trip is a plannedtrip. If a service starting time is not specified,a current time is the service starting time).(starting time of the planned trip. If notpresent, current time is assumed.)tollRoadxsd:booleanYesIt indicates whether passing through a toll roadis allowed. (If true or not present, a toll road isallowed.)vehicleTypeVehicle_InfoYesInformation about a used vehicle(Vehicle_Info structure is defined in tpeg-rtmML [TTI RTM].)calculateRoutexsd:booleanYesIt indicates whether the server provides acalculated route. (If false or not present, theserver should not propose routes.)linkcommon:LinkYesLin information about routes defined in the[0 . . . unbounded]trip. (Links to routes related to the trip.Attribute “rel” must be set to “Route”.)resourceURLxsd:anyURIYesSelf-referring URL information (Self-referringURL. SHALL NOT be included in POSTrequests, MUST be included in responses toany HTTP method that returns an entity body,and in PUT requests.)
2) Route Structure: a route structure is expressed as a plurality of segments as a way to represent total routes calculated using the trip structure.
TABLE 2ElementTypeOptionalDescriptiontravellingTimexsd:floatYesTotal travelling time (in minutes) for the routedistancexsd:floatYesTotal distance (in Km) of the routeoriginLocation_PointNoOrigin of the route (represented by WGS84)(Location_Point structure is defined in tpeg-locML [TTI LOC].)segmentSegmentNoSequence of road segments that form the route[1 . . . unbounded]trafficEventsCategorizedEventYesInformation about links accessing trafficListReferenceinformation resources (List of traffic events as[0 . . . unbounded]defined in tpeg-rtmML [TTI RTM], groupedinto categories.)linkcommon:LinkYesReference to the route for which it is proposedas alternative. Attribute “rel” must be set to“Route”.resourceURLxsd:anyURIYesSelf-referring URL. SHALL NOT be includedin POST requests, MUST be included inresponses to any HTTP method that returns anentity body, and in PUT requests.)
3) Segment Structure: it is a structure that represents each segment. The segment structure may define a real-time traffic state corresponding to the segment as well as the length of the segment, in TPEG.
TABLE 3ElementTypeOptionalDescriptionendPointLocation_PointNoLocation information about the end point of eachsegment (represented by WGS84)(Location_Pointstructure as defined in tpeg-locML [ITT LOC]. Thestarting point of the segment should be assumedequal to the ending point of the previous segment (orthe trip origin for the first segment))midwayPointLocation_PointYesLocation_Point structure as defined in tpeg-locML[0 . . . unbounded][TTI LOC].linkNamexsd:stringYesName of the road that the segment belongs todistancexsd:floatYesLength of the segment in kmtravellingTimexsd:floatYesEstimated average time to cover the segmentexpressed in minutes. It includes regular travellingtime and delay.delayxsd:floatYesEstimated delay along the segment expressed inminutes.speedxsd:floatYesEstimated average speed along the segmentexpressed in m/s.performancexsd:stringYesInformation about traffic state (levels may be definedto indicate delay, congestion, and severe congestion).(Description of traffic conditions along the segment.This field should be encoded according to tpegrtmML definition [TTI RTM].)
FIG. 2 is a diagram illustrating a signal flow for an operation of a lightweight ND in a conventional DynNav system. Because the lightweight ND does not support route calculation in view of its capability, the lightweight ND should request route information to a server and receive the route information from the server. The lightweight ND has the following main functionality.
1. The smart ND transmits trip information to the server, for use in route calculation at the server.
2. The smart ND receives information about a set of routes (including a recommended route) calculated by the server from the server.
3. The smart ND subscribes to a notification service to receive real-time traffic information from the server.
The signal flow illustrated in FIG. 2 contains the followings, on the whole.
1. The user defines journey parameters, and the application sends the parameters to the server; the server calculates a set of proposed routes based on the received parameters with related traffic information. The server replies with the location of the created “trip” resource to the application.
a) The server may reply with a representation of the created “trip” resource. In this use case, behaviors are equivalent.
2. The application uploads the calculated route to resource/{tripId}/routes. The server may replay with a representation of a “route” resource containing performance parameters and links to traffic events.
a) The server may reply with traffic information (performance parameters and traffic events). In this case, additional GET operation is necessary to retrieve the resource.
3. The application subscribes to a notification service for a trip and route.
4. The traffic events and/or performance parameters are modified for the subscribed route(s); Notification resource is created.
5. The server delivers the notification resource to the application using links to the modified resources with the trip and route containing the updated performance parameters and traffic information.
6. The application accesses the updated resources and reads the resources.
7. The application decides to calculate a new route using the received resources.
8. The application uploads the newly calculated route to resource/{tripId}/routes. The server replies with a representation of the “route” resource containing route performances and links to events. This step may be repeated several times until a route satisfying performance restriction is found.
9. The application requests to modify subscription setting for adding notification of the newly subscribed route.
FIG. 3 shows operation of a smart ND described with reference to FIG. 2 when a destination is a third terminal (that is, a target terminal 34).
For fast GPS connection and additional support information delivery between a navigation terminal (that is, a source terminal 31) and a location server 33 before performing a navigation service, positioning assistance data (A/D) is shared between the source terminal and the location server using a location information delivery protocol.
S301: The source terminal 31 performs a service for setting the location of the target terminal 34 as a destination. In this step, an identifier (ID) for identifying the target terminal is used to specify the target terminal. Here, a globally unique value of a terminal, such as Ipv4 address, Ipv6 address, MSISDN, IMSI, etc., is used as the identifier.
S302: The source terminal delivers the identifier of the specified target terminal and notifies a traffic information server 32 that the service for setting the location of the target terminal as the destination is performed. In this step, for the service, the source terminal delivers the location information thereof to the traffic information server.
S303: The traffic information server requests permission to use the location information of the target terminal and to perform the service from the target terminal and receives a response for accepting the request. In this step, if the target terminal does not accept the request, the service is not performed.
S304: If the target terminal accepts performance of the service in S303, the navigation service starts.
S305: The traffic information server requests the location information of the target terminal via the location server 33 as soon as the navigation service starts.
S306: The location server acquires the location information of the target terminal according to the request of the traffic information server.
S307: The location server transmits the location of the target terminal acquired in S306 to the traffic information server.
S308: The traffic information server delivers the location information of the target terminal acquired in S307 to the source terminal. At the same time, partial traffic information may be provided. The partial traffic information includes detailed traffic information (performance parameters) of the vicinity (within a certain radius) of a departure point and traffic event information (traffic event) from the departure point to the destination based on the location of the source terminal delivered by the source terminal in S302 and the location of the target terminal delivered by the location server in S307.
S309: The source terminal calculates an optimal route based on the location of the target terminal and the partial traffic information received in S308.
S310: The source terminal registers the route acquired in S309 with the traffic information server. The route is registered with the traffic information server in order to receive, from the traffic information server, traffic condition change (that is, traffic information=detailed traffic information+traffic event information) of the route based on the registered route in addition to a current traffic condition based on the registered route.
S311: The traffic information server delivers the current traffic condition of the registered route information to the source terminal, in order to calculate an estimated time of arrival of the source terminal on the route. Since information on traffic accidents or construction on the route is delivered in S308, re-calculation of the route is not performed.
S312: The location server may track the location of the target terminal on a predetermined cycle (temporal cycle) and deliver the location information to the traffic information server or continuously track the location of the target terminal and deliver the location information to the traffic information server only when a movement distance is satisfied.
S313: The traffic information server delivers the received location of the target terminal to the source terminal.
S314: The source terminal re-calculates the route (or performs re-searching) based on the received location of the target terminal. After the route is re-calculated, the operation returns to S309 to repeat S309 to S314 repeated.
The smart ND of the conventional DynNav system described with reference to FIGS. 2 and 3 has several problems.
1) Problems Occurring when the Smart ND Operates on a Predetermined Cycle
If the location server receives and delivers the location information of the target terminal to the source terminal on a temporal cycle, for example, if it is assumed that the location server obtains the location of the target terminal at an interval of 5 min, assume that the location of the source/target terminal is hardly changed for 5 min. After 5 min has elapsed, when the source terminal acquires the location of the target terminal and re-calculates the route ting based on the acquired location, the re-calculated route may be hardly changed from the existing route. In this case, since the route is unnecessarily re-calculated, overhead occurs in data processing, transmission and reception.
2) Problems Occurring when the Source Terminal Decides Route Re-Calculation
The source terminal does not have traffic condition information and decides route re-calculation using the location thereof and the location of the target terminal. In such a decision process, an actual traffic condition may not be considered. That is, if the current location of the target terminal is not included in an existing route, since traffic condition information from the existing route to the current location of the target terminal is not present, a probability that the re-calculated route does not include an actual traffic condition is very high.